fix(bindx): stop writing a child that its parent deletes - #102

What was broken

A child entity that is dirty and already scheduled to be removed by its parent got its own top-level update<Entity> mutation on top of the nested delete in the parent's update. With the default sequential adapter (ContemberAdapter has no persistTransaction) the parent update runs first and the row is gone, so the standalone update answers NotFoundOrDenied and the whole save is reported as failed — while the deletes have already landed on the server.

This PR covers both relation kinds, which are the same bug:

• has-many (issue Standalone update emitted for a has-many item planned for delete — NotFoundOrDenied after the parent's nested delete #91): an item in plannedRemovals with type delete. The everyday trigger is a sortable Repeater / BlockRepeater: remove() renumbers the surviving items before field.remove(id), so removing two or more items in one gesture leaves every later-removed item dirty and removed at the same time.
• has-one (the twin, found while fixing the above): a target whose relation is in state deleted, removed by the parent's { delete: true }. Same failing shape, same cause.

The fix — two halves, one set

1. No standalone update for a child its parent deletes.
A refcounted PlannedDeleteIndex (shared the way RelationEdgeIndex already is) tracks the children some relation plans to delete through its parent. Each relation sub-store maintains it in its own single write chokepoint by diffing previous state against next — HasManyStore.writeHasMany/deleteHasMany for plannedRemovals of type delete, HasOneStore.writeRelation/deleteRelation for state deleted. No second write path, no scanning of relation state on read. RelationStore.isPlannedForDeleteByParent unions the two sub-stores, SnapshotStore re-exposes it, and BatchPersister.buildMutations skips the standalone update of such an entity.

The has-one side indexes serverId, not currentId: MutationCollector deletes serverId for a deleted relation, and a null serverId emits no delete at all, so that target must keep its own update.

The skip sits in buildMutations rather than in DirtyTracker.getAllDirtyEntities. That placement is load-bearing: entity:persisting interceptors are offered exactly the dirty entities, and a veto there is what suppresses the parent-side delete (see 54bf2b0). Dropping the item from the dirty set makes it unvetoable — three existing tests in vetoedDeleteStaysPending.test.ts and nestedDeleteOfDirtyEntity.test.ts fail that way. Keeping it in the dirty set and only withholding its mutation preserves both contracts, on both relation kinds.

2. Purge the child after a confirmed nested delete — why this is needed.
Without it the first save succeeds and the bug comes straight back. After a confirmed nested delete the child's snapshot survived in the store and stayed dirty: reconcileConfirmedEntities called store.removeEntity(...) only for entities whose own top-level operation was delete, while the relation loops folded the removal into the server baseline and never dropped the child. Once commitAllRelations cleared the planned removal, the child was dirty again, the save button stayed dirty, and the next save emitted an update for a row that no longer exists — the same NotFoundOrDenied.

reconcileConfirmedEntities now drops the children of every confirmed has-many removal of type delete and of every confirmed has-one delete transition, mirroring what the top-level delete path already does. The child's type comes from the collected relation fields, the only place a nested child's entity type is recorded.

Both halves now cover exactly the same set. An earlier revision of this branch purged both relation kinds but suppressed the update for has-many only; on the has-one path that dropped the target from the store while still sending its update, and processing that update's result resurrected a snapshot whose data had lost its id field. That is fixed here, and pinned by a test.

Deliberately untouched:

• disconnect removals and plain has-one disconnects keep their standalone update — the row survives.
• entities that are themselves scheduleForDeletion-ed keep reporting delete and keep their own mutation alongside the parent-side delete (54bf2b0).
• created (never-persisted) items never reach the index: removeFromHasMany cancels their plannedAdditions entry instead of planning a removal.

How it was verified

• The reporter's failing repro is cherry-picked as-is (authorship preserved) and confirmed failing before any source change — the standalone updateTag(tag-2, { order: 0 }) was emitted after the parent's deletes.
• The has-one twin was pinned by a test written before its fix and confirmed failing: a standalone updateBlock was emitted next to cover: { delete: true }, and the ghost snapshot came back as data: { title: "Edited" } with no id.
• Added coverage: the deleted child is gone from the store and getAllDirtyEntities() is empty after a successful save (the regression that would otherwise re-open this on the second save), for both relation kinds; disconnect keeps its standalone update and its snapshot; a created-then-removed item stays out of the persist entirely; a has-one target vetoed by an entity:persisting interceptor is still skipped, still suppresses the parent-side delete, and keeps its snapshot.
• Full suite: 2018 passing, 0 failing (bun run test, everything except tests/browser).
• bun run typecheck clean, bun run lint reports 0 errors (17 pre-existing warnings, none in the touched files).

Fixes #91 — and the has-one variant of the same bug, which was never filed separately.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Euwkf2wtutqvtE4YRutU5R